- From: Dave Singer <singer@apple.com>
- Date: Tue, 31 Jul 2007 16:58:09 -0700
- To: public-html WG <public-html@w3.org>
I think one of the tricky things about accessibility is coming up with a specification that is not only effective when used properly, but naturally leads people to using it properly. I'll give an example from another field. The installer used on Mac OS X requires that if you choose "custom install", the user is shown the various pieces that might get installed, with a check-box for the optional pieces. Selecting an optional piece shows an explanatory string for what you get if you install that option. I cannot tell you the number of times I have seen something like "Frobotz 2" as an optional install, and wondered if I needed it or not, clicked on it to find out what it was, and been given the explanatory string "This installs the Frobotz 2 option". Which is useless to me. Requiring (this is an example only) a text description of elements may be counterproductive. Authoring tools or authors might, for example, insert "this is an image" as the default description of all images. Now browsers, crawlers, analyzers etc. cannot tell easily whether an element has a real (useful) text description or not. Indeed, a browser that tries to "say something useful" about un-described elements now is "blocked" by these apparent (but useless) descriptions. So, I actually think, despite the heat on the mailing list, we are somewhat on the same page. We're looking for a specification in which people "naturally" do the right thing, where at least reasonable accessibility is normal, good is possible, and poor is detectable. This isn't easy; it's a subtle trade-off of designs, mandates, recommendations, and examples. -- David Singer Apple/QuickTime
Received on Tuesday, 31 July 2007 23:58:44 UTC